One challenge faced by many software development organizations is the need to continually create usable builds of a software system under development (SSUD). A software development organization must ensure that there is always a build that is usable and that includes the most recent program code updates so that downstream parties may utilize the build for a variety of reasons. Examples of downstream parties include, but are not limited to, test teams within the development organization itself, early adopters such as customers and end-users, integrating partners such as third party development organizations that create products that interact with the SSUD, and the like.
A “build process” is the process of converting software artifacts such as source code files into standalone software artifact(s) that can be run or executed on a computer. A “build” is the result of the build process, e.g., the resulting executable software system. The build process typically includes compilation where source code files are converted into executable program code. In the case of a less complex SSUD, the build process may consist of a single file being compiled. For a more complex SSUD, however, the build process may involve many files that may be combined in different ways to produce many different versions of the SSUD.
Typically, the software development organization attends to the challenge of providing usable builds by creating a series of different builds of the SSUD. The builds are rated on a stability continuum where one end of the continuum is considered least stable and the opposite end of the continuum is considered most stable. The more stable the build, the more stringent the controls that determine what program code may be contributed to the build for purposes of further development and/or bug fixes.